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REMARKS 

Claims 1 and 3-4 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Croslin, further in view of Beurket et al. Claim 2 has been rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Croslin, further in view of Beurket et al. and Guenthner et al. Claims 5- 
7 were rejected "for similar reasons." 

As discussed during the Interview, the Examiner's continued reliance on Croslin is 
believed to be misplaced for the reasons set forth below. Accordingly, these rejections are 
traversed. 

The undersigned illustrated to the Examiner during the Interview that the present 
invention uses physical probing of physical devices on a network to generate relevant data; the 
portions of Croslin relied upon by the Examiner involve software-driven analysis of a database 
table that allegedly illustrates a set of physical telecommunications links. Thus, in the present 
invention, a relevant method step calls for physical acts to take place over a physical network; at 
most, Croslin simply teaches analyzing a "representation" of a physical network, not performing 
the relevant tests on the physical network itself. 

Amended Claim 1 and amended claim 5 describe this physical probing explicitly: 

"for a given pair of data centers each accessible over the Internet, physically executing a 
trace route over the Internet from each data center to a given local J$§fpie server" (claim 1 ) 

"for each local name server, physically directing a trace route over the public Internet 
from each content provider mirror site to the local name server" (claim 5); 

Independent claim 7 is even more specific about the physical probing: 

"dynamically determining a set of proxy points, wherein each proxy point of the set of 
proxy points is determined by physically directing a trace route over the public Internet from 
each of the set of mirror sites toward a given name server and determining a given point in the 
public Internet where the trace routes from each of the set of mirror sites intersect." 

The above amendments clarify the physical nature of the method step at issue, and this aspect 
of the present invention is completely absent from Croslin or any of the other cited art. 

In particular, Croslin describes a system 200 that runs a restoration process 208, which is 
a software routine. The process 208 reads and writes data from a restoration database 212. This 
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data includes a series of tables that represent the network topology and are used to develop the 
restoration routes. As described in Figure 5, there are a series of steps performed to generate a 
restoral route for a given impacted trunk of the telecommunications network. Initially, an 
"intersection table" is built that identifies instances where a sub-route that originates from a 
given "lefthand" node intersects (i.e. shares at least one common node) with a sub-route that 
originates from a "righthand" node. A lefthand node is one that lies to the left of the network 
outage and a righthand node is one that lies to the right of the network outage. According to the 
patent, the lefthand node is "folded out" to identify from the sub-route table all nodes that are 
end nodes from a sub-route that begins from the node being folded out. Once the intersection 
table (see Figure 10) for the impacted trunk is generated, the table can be read to determine the 
restoral route. In particular, the restoration process 208 checks whether an intersection is found 
in the intersection table. If so, an optimal intersection route is selected^ and this is typically the 
route with the lowest cost. The selection of the route constitutes a selection or combination of 
the two end node pairs that intersect, as indicated by the data in the table. 

The written description of the present invention relates to a technique for generating a 
network map for a user-base of the Internet. Instead of probing each local name server that is 
connectable to a mirrored data center, however, the network map identifies connectivity with 
respect to a much smaller set of points, referred to in the applications 1 "core" or "common" 
points. Each set of mirrored data centers preferably has an associated map that identifies a set of 



that is physically executed (i.e., run) from each of the set of mirrored data centers to a local name 
server. As discussed during the Interview, a "trace route" (or "traceroute") is a computer 
network test used to determine the route taken by data packets across an actual IP network. This 
is a real test carried out on a real network , not simply a software instruction executed against a 
database representation, as in Croslin. An intersection of the trace routes at a common routing 
point is then identified. The core point discovery process is illustrated in Figure 3. Preferably, 
the trace routes are between data centers and local name servers. The core points are the , 
intersection point of a trace route or near or substantially near the intersection point. 

Unlike the present invention, Croslin does not locate intersection points utilizing trace 
routes performed on the actual Internet. Croslin builds sub-route tables based upon nodes 
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identified by topology data. Points are identified from these database tables, and not from a trace 
route that is actually performed in a network being mapped. 

In addition, in considering Croslin, it should be noted that each of the pending claims 
concern testing an actual network with respect to an Internet "name server." Claim I emphasizes 
this, e.g, by reference to "a local name server address space" and executing trace routes "to a 
given local name server." Likewise, claim 5 refers to "end user local name server requests" in 
the preamble and requires that the routes are physically traced from each mirror site "to the local 
name server." Claim 7 states that the "client request" is a "client name server request," and this 
claim also states that the routes being run intersect at a "given name server." Croslin, which 
concerns a voice/data telecommunications network, says nothing about Internet name servers, 
name server address space maps, name server locations, trace routing to name servers, or the^ 
like. These "name server" limitations in each claim are meaningful, and they are neither . 
disclosed nor suggested in Croslin. 

As was also mentioned at the Interview, neither Buerket et aL nor Guenthner et al., the 
secondary references, make up for the deficiencies in Croslin. In particular, neither reference 
discloses (nor does the Examiner say otherwise) the physical probing of a physical network to 
facilitate generation of a proxy point map according to the present invention. 

Accordingly, all claims should now be considered allowable, "and a notice to that effect is 
respectfully requested . Hi" . 



David H. Judson \ 
Registration No. 30,467 
(972)385-2018 




Date: May 3, 2006 
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